Are the 2 CI failures the problematic ones? These are with old GHCs only, right?

Yes, but the source packages still work on those older GHCs so ideally we should be able to as well.

For the GHC 8.4.4 failure:

rejecting: ghc-8.4.4/installed-8.4.4 (conflict: binary==0.8.9.1, ghc => binary==0.8.5.1/installed-0.8.5.1)

It thinks the installed version of the ghc package, 8.4.4 specifically depends on the installed version of the binary package, 0.8.5.1, when in actual fact ghc-8.4.4 on hackage can use binary [0.8, 0.9). I'm guessing that cabal is artificially restricting the version choice here to "installed packages can only depend on other installed packages" but I don't know how to override it.

In fact, ghc package is not re-installable currently, so cabal is doing the right thing, but communicating it wrongly: haskell/cabal#8501

Why do we depend on binary here

https://github.com/haskellari/strict-containers/blob/master/strict-containers/strict-containers.cabal#L75

? Neither containers nor vector does. Even more unexpectedly, whey are we depending on ghc?

Oh, I see, ghc dep comes from

https://github.com/haskellari/strict-containers/blob/master/strict-containers-tests/strict-containers-tests.cabal#L44

and the binary dep as well.

Perhaps this test should be disabled for the old GHCs?

Sadly, currently, anything that depends on boot packages needs to work with the versions of their deps they have been compiled with and the boot packages can't be recompiled. The kind GHC folk are working on lifting this restriction ("reinstallable ghc library", if I'm not mistaken).

OK, yes #haskell also convinced me the current task is impossible. Simplest solution probably is indeed to disable that test for older GHCs.

binary dep is for instances. They could be lifted out into a separate package if the dependency continues causing problems, but I think we can avoid that for the time being.

GHC 8.2 failure is probably blocked on well-typed/cborg#302

well-typed/cborg#302 is done.

it needs to be released to hackage of course, for the failing CI to have a hope of succeeding

oh

it needs to be released to hackage of course, for the failing CI to have a hope of succeeding

It is, https://hackage.haskell.org/package/serialise-0.2.6.0/revisions/

So probably a restart of CI would be enough?

OK I guess they released the PR to hackage before it was merged, as the date shows Oct 23 but the PR was merged just a few days ago. I restarted the CI yesterday already and it's still failing. Taking a look, this is because:

[__4] rejecting: serialise-0.2.6.0 (conflict: base==4.10.1.0/installed-4.10.1.0, serialise => base>=4.11 && <4.18)

Probably, the simplest solution is to drop support for the older GHC in strict-containers-serialise.

Yes, they seem to have applied a revision on Hackage ahead of the PR, possibly without even knowing about each other.